In order to print images and texts from an application executed by a host computer using a print apparatus, an operating system is generally provided with a configuration such as that shown in FIG. 3. More specifically, an application 101 hands over graphics data to a graphics engine 103, and the graphics data is processed by the graphics engine 103 before being handed over to a printer driver 104. The printer driver generates print data (generally referred to as PDL [Page Description Language]) corresponding to a print apparatus. The print data is stored in a spooler 105, and then sent to a print apparatus 1500.
In particular, the graphics engine 103 performs processing of graphics data such as converting the dimension of graphics data created by the application 101 or simulation processing according to the throughput of the printer driver 104. Therefore, the application 101 and the printer driver 104 are both capable of independent operation. The graphics engine 103 is normally provided as a part of an OS (operating system) 102.
On the other hand, the number of graphics engines 103 is not necessarily limited to one. Some configurations (OSs) allow two or more graphics engines to coexist.
For instance, a hardware engineering conference titled WinHEC-2005 was hosted by Microsoft Corporation in 2005 in Seattle, USA. At the conference, Microsoft's new OS (named Windows [registered trademark] Vista) was introduced as having a configuration in which two graphic engines coexist, as shown in FIG. 1 (Daniel Emerson, “Advances in Windows Printing”, WinHEC 2005 Conference (TWPR05001_WinHEC05.ppt)).
Microsoft's conventional printing systems use a graphics engine called GDI (Graphic Device Interface) through an application (hereinafter referred to as a Win32 application) using an API (Application Programming Interface) referred to as a Win32 API, where print data is created from graphics data by a printer driver (hereinafter referred to as a GDI printer driver) called from the GDI. In the present embodiment, this print processing flow shall be referred to as a GDI print path.
For Windows Vista, a new print processing flow, referred to as an XPS print path, will be provided in addition to the conventional GDI print path. For the XPS print path, a graphic engine called a WPF (Windows Presentation Foundation) is provided by the OS through an application (hereinafter referred to as a WinFx application) using an API called WinFx API. The WPF graphics engine hands over XPS (XML Paper Specification) format graphics data to a printer driver (hereinafter referred to as an XPS printer driver), whereby the printer driver converts the graphics data to print data.
The GDI and WPF graphics engines are also capable of collaborating with each other. This collaboration enables graphics data to be handed over from a Win32 application to the XPS printer driver, or from a WinFx application to the GDI printer driver.
In order to make this collaboration work, when printing from a WinFx application using the GDI printer driver, graphics data is first converted into XPS format graphics data by the WPF graphics engine, and then from XPS format graphics data to EMF format graphics data. The converted graphics data is stored in an EMF spool file, and subsequently converted into print data by the GDI driver.
In addition, when printing from a Win32 application using the XPS printer driver, graphics data is first converted into EMF format graphics data by the GDI graphics engine, and then from EMF format graphics data to XPS format graphics data. The converted graphics data is stored in an XPS spool file, and subsequently converted into print data by the XPS printer driver.
As described, four print processing flows are provided in Windows Vista. Thus, print processing from both Win32 applications and WinFx applications may be realized by preparing either one of a GDI printer driver or an XPS printer driver.
However, since the XPS format and the EMF format differ from each other, conversion of graphics data formats has problems in terms of print quality, print functions, print speed and the like.
For instance, graphics data containing logic operations such as ROP operations (or raster operation processing operations), which is supported in EMF format, is not supported in XPS format. Therefore, depending on specifications specified by Microsoft Corporation, there is a risk that logic operation information may be lost from graphics data containing logic operations when undergoing conversion by a GDI-GPS conversion module that converts EMF format into XPS format. When graphics data, from which logic operation information is removed, is handed over to the XPS printer driver, the XPS printer driver may not be able to create the output result intended by the Win32 application.
Conversely, sophisticated graphics data that is supported in XPS format is not supported in EMF format. For this reason, when performing conversion using an XPS-GDI conversion module that converts XPS format into EMF format, such graphics data is converted into localized bitmaps in a process called flattering. In this case, since graphics data is converted into bitmap data, the GDI printer driver will be unable to determine original object properties, and therefore will be unable to create an output result corresponding to the object properties. In other words, quality of images output through data format conversion will deteriorate. For instance, when printing multiple pages per sheet using a printer driver, since data converted into bitmaps will be scaled down and arranged, image quality will be lower than a case in which a graphical object is drawn in a reduced size.
Furthermore, for instance, electronic signature information that is supported in XPS format is not supported in EMF format. Moreover, processing that is supported in EMF format, in which information from an application is directly conveyed to the GDI printer driver, is not supported in XPS format. Therefore, when a conversion from XPS format to EMF format or vice versa is performed in the event that graphics data in the pre-conversion format contains instructions using functions which are not supported in the post-conversion format, such functions will not be performed. In other words, functions that are not achievable when data format conversion processing is performed may exist in graphics data of respective formats.
Additionally, the occurrences of processing for GDI-XPS conversion or XPS-GDI conversion and the like may result in processing overhead, and therefore print processing speed may be reduced in comparison to processing paths that do not require conversion.
As described, when data format conversion is performed, problems arise in all of the aspects of quality, function and speed. Therefore, it is desirable to avoid print processing paths that involve data format conversion.
On the other hand, when both an XPS printer driver and a GDI printer driver for the same print apparatus are installed in a computer, the selection of the printer driver to be used is left to the user's discretion. In other words, in Windows (registered trademark) Vista, the graphics engines will not automatically select processing paths that do not require data format conversion. Furthermore, most users are not conscious of whether a certain application is a Win32 application or a WinFx application, and are unaware that four print processing flows exist. Therefore, when one printer driver is selected as a default printer driver, the selected printer driver will be used regardless of application type. As described, in print processing paths, avoiding data format conversion such as GDI-XPS conversion or XPS-GDI conversion may prove difficult.